Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-thinosi-cookbook-00.txt < prev next >

Wrap

Text File | 1993-08-09 | 67KB | 1,596 lines

Thinosi Working Group P.R.Furniss INTERNET DRAFT Consultant August 1993 Octet sequences for upper-layer OSI to support basic communications applications Status of this Memo This draft document is part of the work of the IETF Thinosi Working Group. It is intended to submit it to the IAB standards track. Distribution of this memo is unlimited. Comment on this draft should be sent to the thinosi mailing list: thinosi@ulcc.ac.uk. Requests to join this list should be sent to thinosi-request@ulcc.ac.uk. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id- abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, ic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract This document specifies those elements of the OSI upper-layer protocols (Session, Presentation and ACSE) needed to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and Directory Access Protocol, and "migrant" protocols, originally defined for use over other transports. The upper-layer protocol elements are specified in this document as the particular octet sequences that comprise an "envelope" around the application protocol's data. It therefore independent, as a document, from the OSI base standards, although an implementation based on this document will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol. Expires 11 February 1994 [Page 1] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 Table of Contents 1. Introduction ....................................................3 2. General .........................................................3 2.1 Subdivisions of "basic communication applications" ............3 2.2 Conformance and interworking ..................................5 2.3 Relationship to other documents ...............................6 2.4 Model of an implementation ....................................6 3. Contexts and titles .............................................7 3.1 The concepts of abstract and transfer syntax ..................7 3.2 Use of presentation context by the cookbook applications ......8 3.3. Processing Presentation-context-definition-list ..............8 3.4 Application context ...........................................9 3.5 APtitles and AEqualifiers .....................................9 4. What has to be sent and received ...............................11 4.1. Sequence of OSI protocol data units used ....................11 4.2. Which OSI fields are used ...................................13 4.3. Encoding methods and length fields ..........................14 4.3.1 Session items ..............................................14 4.3.2 ASN.1/BER items (Presentation and ACSE) ....................15 4.4. BER Encoding of values for primitive datatypes ..............15 4.5. Unnecessary constructed encodings ...........................16 5. Notation .......................................................16 6. Octet sequences ................................................17 6.1. Connection request message ..................................17 6.2. Successful reply to connection setup ........................20 6.3. Connection rejection ........................................22 6.4. Data-phase TSDU .............................................22 6.5. Closedown - release request ................................24 6.6. Closedown - release response ................................24 6.7. Deliberate abort ............................................25 6.8. Provider abort ..............................................26 6.9. Abort accept ................................................27 7. References .....................................................27 8. Other notes ....................................................28 9. Author's Address ...............................................28 Expires 11 February 1994 [Page 2] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 1. Introduction The upper-layer protocols of the OSI model are large and complex, mostly because the protocols they describe are rich in function and options. However, for support of most applications, only a limited portion of the function is needed and the protocol elements needed can be expressed more simply. This memo describes the protocol elements required by the OSI upper layers when supporting a connection-oriented application with only basic communication requirements - that is to create a connection, optionally negotiate the data representation, send/receive data, close a connection and abort a connection. Optionally, data may be sent on the connection establishment, closing and abort messages. The protocol elements for the OSI upper layer protocols (i.e. Session , Presentation . and Association Control Service Element (ACSE) . needed to support such an application are a subset of the full protocols defined in the International Standards ([ISO8326, ISO8327, ISO8822, ISO8823, ISO8649, ISO8650]). Such a protocol subset can be specified in a profile, which references the base standards and states which parts are relevant. Such a profile specification cannot be understood without reference to the base standards. In this memo, the protocol elements needed are specified in terms of the octet sequences that comprise the 'envelope' around the application data. This memo thus provides a re-specification of the relevant parts of the upper-layer protocols. An implementation based on this memo will be able to interwork with an implementation based directly on the full standards when both are supporting a basic communication application. (The "full" implementation will exhibit only part of its potential behaviour, since the application will only invoke part).The envelope and its enclosing data form a Transport Service Data Unit (TSDU) that can be passed via the OSI Transport Service [ISO8072] (which in turn may be supported as specified in [RFC1006] or any class of the OSI Transport Protocol [ISO8073]). 2. General 2.1 Subdivisions of "basic communication applications" Distinctions can be made within the "basic communication applications", as defined above, based on how much use they make of the OSI upper-layer services. In particular: a) whether application data is sent on the connection establishment, close and abort, or only during "date phase" on an established connection; Expires 11 February 1994 [Page 3] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 b) whether the application data is of only one kind (abstract syntax) and one format (transfer syntax) or more than one (i.e. how much use is made of the Presentation layer syntax negotiation and identification features) These distinctions potentially allow further subsetting, but a large part of the protocol will be the same. In this memo, four groups of supported application are considered, based on these distinctions. All groups have "basic communications requirements" in requiring only connection, data transfer and (perhaps) orderly release of connection.The four groups are: Group I : applications which send data only on an established connection, and use a single abstract and transfer syntax. Group II : applications which send data on connection establishment and release and use a single abstract and transfer syntax. Group III : Applications whose data is in more than one format (presentation context) and which need the syntax identification and negotiation features of Presentation. Further subdivisions of this group are possible Group III applications that send data of only one kind (one abstract syntax) on the connection, but which have more than one format (transfer syntax) specified (they use the Presentation context negotiation facility) Group IV applications that will send data of several kinds on the connection (and which much therefore distinguish on each write which kind is being sent) Group III applications are equivalent to Group I (or possibly Group II) after the establishment exchange has negotiated the particular transfer syntax that will be used on the connection. Possible examples of the Groups are: Group I: application protocols designed for use over transport- level protocols. Typically these are non-OSI protocols "migrated" to an OSI environment. X Window System protocol is an example. Group II: Typically OSI-originated protocols with simple requirements, including many of the ROSE-based ones, such as Directory Access Protocol. Group III: Protocols that can be treated as Group I, but for which more than one encoding of the data is known, such as a standardised one and a system-specific one - all implementations Expires 11 February 1994 [Page 4] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 understand the standard encoding, but Presentation layer negotiation allows like-implementations to use their internal encoding for transfer, without loss of general interworking. The same could apply to OSI protocols. Group IV: OSI protocols with multiple abstract syntaxes but where each message is from a single abstract syntax, and that do not use any of the special Session functional units - X.400 P7 is an example. Some of the OSI protocols that are not included are those that use more than one abstract syntax in a single message (such as FTAM or Transaction Processing) or use Session functional units (RTSE-based protocols, Virtual Terminal). 2.2 Conformance and interworking The protocol elements specified in this memo correspond to the kernel functional units of Session, Presentation and ACSE, and the duplex functional unit of Session. The octet sequences given below are derived from the specifications in the International Standards for the protocols Session [ISO8327], Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo is to summarise those specifications, as applicable to the supported application groups, so that an implementation could be developed without direct reference to the original standards, but capable of interworking with implementations that had made direct reference. The OSI standards (especially Presentation) allow considerable flexibility in the encoding of the protocol data units. Accordingly, this memo defines particular octet sequences to be sent, and describes the variations that can be expected in data received from an implementation based directly on the OSI standards, rather than on this cookbook. It is intended that an implementation that sends these sequences and that is capable of interpreting the variations described will be fully able to interwork with an implementation based directly on the OSI standards. An implementation that is only capable of interpreting the octet sequences specified in this memo for transmission may not be able to interwork with standards-based implementations. The intent is to be able to interwork with conformant implementations in support of the relevant application (or group of applications). Some of the OSI standards have conformance requirements that go beyond that necessary for successful interworking, including detection of invalid protocol. Tests for conformance sometimes go beyond the strict conformance requirements of the standard. Consequently an implementation based on this memo may or may not be able to formally claim conformance to the International Standard. It may be able to legitimately claim conformance, but fail a conformance test, if the test is over-specified. Expires 11 February 1994 [Page 5] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 (Efforts are being made to correct this, but in the meantime, the target is interworking with conformant implementations) 2.3 Relationship to other documents The flexibility allowed in the Session, Presentation and ACSE standards is restricted in the Common Upper-Layer Requirements Part 1 [CULR-1] ). This is a proposed International Standardised Profile (pdISP 11188-1) that can be assumed to be obeyed by most implementations. This memo applies the restrictions of CULR-1, especially where these concern maximum sizes of fields and the like.Points where advantage is taken of a CULR-1 limitation are noted. Additional parts of CULR are under development. Part 3 [CULR-3] covers the protocol elements needed for "basic communications applications", and is being developed in (informal) liaison with this memo. CULR-3 is presented as a normal profile, largely consisting of prescribed answers to the questions in the PICS (Protocol Implementation Conformance Statement) of the three protocols.CULR-3 does not make the distinction between the four Groups.An implementation of this memo (at least if it supported Group IV) would be able to claim conformance to CULR-3, with the possible exception of any more-than-interworking conformance requirements inherited by CULR-3 from the base standards. An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is shortly to be published as a preliminary specification. This defines an API to the OSI upper-layers, again as appropriate to a basic communications application. XTI/mOSI would be usable as an interface to support applications in groups I, II and III, and possibly group IV. 2.4 Model of an implementation This memo does not require any particular structuring of the implementation. An implementation could be developed to support all the groups, or only some of the simpler groups, or a specific application. Nevertheless, the memo defines the protocol to be created and interpreted by a notional component that has an upper boundary to an application that passes to it and receives from it requests for connection, disconnection and sequences of application data. Any internal structure in the application data is transparent to the component. a lower boundary to the OSI Transport layer, to and from which the component passes requests for transport connection and disconnection, and Transport Service Data Units to be sent/received on the T-DATA service. For a general implementation, the upper boundary (interface) will need to distinguish whether the application data is a "single-ASN.1-type" Expires 11 February 1994 [Page 6] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 encoded with the Basic Encoding Rules, or a non-ASN.1/BER octet string(because it changes one octet in the envelope). For group iVapplications it will be necessary to distinguish which syntax the particular data item is in. 3. Contexts and titles 3.1 The concepts of abstract and transfer syntax OSI includes the concepts of "abstract syntax" and "transfer syntax". These are terms for the content (abstract syntax) and format "on-the- line" (transfer syntax) of the protocol elements. The combination of an abstract syntax and transfer syntax is called a presentation context. Application protocols devised explictly under OSI auspices have used ASN.1 for the definition of the abstract syntax, and nearly all use the Basic Encoding Rules applied to the ASN.1 to define the transfer syntax. However, there is no such requirement in OSI in general or in OSI Presentation, and still less is there any requirement to change the representation of existing application protocols to ASN.1 (for their definition) or BER (for their transmission). It is not generally realised (even in OSI circles) that all communicating applications, in all environments, are using some form of these, although under different names and without the explicit identification that the OSI Presentation provides. OSI thus separates the identification of the content and format of the data from the addressing. Formal specifications of non-OSI application protocols (such as TELNET, FTP, X Windows System) generally do not use ASN.1, but will invariably be found to define abstract and transfer syntaxes. For a less formalised protocol used between similar systems, the abstract syntax may be defined simply in programming language structures, and the transfer syntax determined by an available compiler represents this in memory. The OSI Presentation protocol requires that "names" be assigned to the abstract and transfer syntaxes of the application data that is carried. The names are always object identifiers (oids): globally unique names assigned hierarchically. Presentation supports the negotiation of a transfer syntax for a particular abstract syntax - several can be offered and one selected. This transfer syntax negotiation facility may be especially useful for non-ASN.1 syntaxes where there is more than one representation available (perhaps differing in byte-ordering or character code). In such a case, on the connection establishment, all of the transfer syntaxes supported by the initiatior are offered, and any one of these accepted by the responder, at its own choice. If the two systems share some "native" format they can negotiate that, avoiding transformation into and out of Expires 11 February 1994 [Page 7] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 the more general format. Following the negotiation, the application can be regarded as if it were group I. The same applies to an ASN.1-defined abstract syntax, but in practice non-BER encodings of ASN.1 are rare. (An ASN.1-defined abstract syntax could be treated as a Group III application offering the BER transfer syntax and some implementation- specific representation as alternatives - if the responder is the same implementation, an efficiency gain is possible.) 3.2 Use of presentation context by the cookbook applications For an application where the application data can be treated (by this component ) as an unstructured stream of bytes, there will be a "real" abstract syntax and transfer syntax, but these will be understood and processed by the "application". For such application protocols there is no need to identify the abstract and transfer syntaxes being used - they are known by some other means (effectively inferred from the addressing). A generic (anonymous, if you like) name for both syntaxes can be used. However, in some cases object identifier names will be assigned for the syntaxes of the application protocol. In these cases, it will be appropriate to use them. It would even be legitimate to offer both the generic and specific names, with the responder accepting the specific (if it knew it) and the generic if the specific were not known - this will provide a migration option if names are assigned to the syntaxes after implementations are deployed using the generic names. CULR-3 defines object identifiers for "anonymous" abstract and transfer syntax names (currently called "default", but this is expected to change). For abstract syntaxes defined in ASN.1 object identifier names will have been assigned to the abstract syntax with the specification. This name MUST be used to identify the abstract syntax. The transfer syntax will most often be the Basic Encoding Rules (BER) object id, but alternatives (e.g. Packed Encoding Rules) are possible.. For group III and group IV applications, specific object identifier names must be used for all the abstract and transfer syntaxes. If these names are not assigned with the specification (e.g. if the specification not in ASN.1) they can be assigned by whoever needs them --- ideally the "owner" of the syntax specification. 3.3. Processing Presentation-context-definition-list In Presentation context negotiation on connection establishment the initiator sends a list (the presentation context definition list) of the abstract syntaxes it intends to use, each with a list of transfer syntaxes. Each presentation context also has an integer identifier. To build the reply, a responder has to examine this list and work out which of the offered presentation contexts will be accepted and which (single) transfer syntax for each. The responder sends back the reply field, the Presentation-context-definition-result-list, in the accept message. The Expires 11 February 1994 [Page 8] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 result list contains the same number of result items as the definition- list proposed presentation-contexts. They are matched by position, not by the identifiers (which are not present in the result-list). An acceptance also includes the transfer syntax accepted (as there can be several offered). This can be copied from the definition list. For the group I, group II and group III cases, only the ACSE and one application-data P-context will be used and all other contexts rejected. For the group IV case, several presentation contexts will be accepted. However, even for group I applications there may be synonyms for an application-data Presentation-context. Unknown synonyms are rejected. The reply shown in 6.2 includes a rejection (It can therefore not be the reply to the connection request shown in 6.1, since that has only two items in the definition list.) In all cases, the connection responder must identify and keep the presentation context identifiiers (called pcid's here) for all the accepted presentation contexts. These are integers (odd integers, in this case). CULR-1 limits them to no greater than 32767, but they will probably usually be <= 255 (so taking up one octet). A presentation context is sometimes used (i.e. data is sent using it) before the negotiation is complete. As will be seen in section 6, in these cases, the transfer syntax name sometimes appears with the integer identifier. 3.4 Application context The Association Control Service Element also exchanges the name (another Object Identifier) of the application context, which identifies what the communication is all about, again independently of the naming and addressing. As for the syntaxes, although some name must be present in the protocol, a generic name can be used for applications that do not have a specific name assigned. (This will almost certainly be a group I application - if a specific name is assigned, it MUST be used.). The only negotiation allowed is that the reply may be different from that sent by the initiator. CULR-3 provides a generic application context name (i.e. assigns an object identifier). 3.5 APtitles and AEqualifiers In addition to the addressing constructs (transport address and possibly session and presentation selectors), the communicating application entities have names - Application-Entity titles (AEtitle). These are carried by ACSE as two fields -the Application-process titles (APtitle) and the Application-entity qualifier (AEqualifier). The AEtitle is compound, and the APtitle consists of all but the last element, which is the AEqualifier. (This explanation can be run backwards). There are two non-equivalent forms. AP-titles and AE-titles can be Directory Name or Expires 11 February 1994 [Page 9] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 an Object Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or an integer - the forms must match, since the AE-qualifier is the last component of the AP-title. In practice, the Directory form is likely to be the only one seen for a while. Use of the these names is rather variable. This cookbook proposes that implementations should be able to handle any value for the partner's names, and set (as initiator) its own names. This is primarily to facilitate OSI:non-OSI relaying (e.g. X/osi:X/tcp), allowing the names of the end-system to be carried to the relay, where they can be converted into hostnames, and the lower-layer address determined. OSI assumes that name-to-address lookup is possible (via the Directory or other means), but does not assume address-to-name will work. Thus the calling AE-title is needed if the responder is to know who the initiator is. However, most protocols work perfectly well without these names being included. As for their encoding, a RDN will almost always be a single attribute value assertion, with the attribute defined either by the Directory standard [ISO9594 = X.500], or in [Internet/Cosine Schema][RFC1274]. Using the notation defined below, the encoding of an RDN using a Directory-defined standard attribute is: 31 80 {1 - RDN, [SET OF] 30 80 {2 - AttributeValueAssertion, [SEQUENCE] 06 03 5504yy -- OID identifying an attribute named in -- the Directory standard -- which one is determined by yy 13 La xxxxxx -- [Printable string] -- could be T61 string, with tag 14 00 00 }2 - end of AVA 00 00 }1 - end of RDN The most likely attributes for an RDN have the following hex values for yy CommonName 03 Country 06 Locality 07 State/Province 08 Organisation 0A OrganisationUnit 0B For non-Directory attributes, the object id name must be substituted (thus changing the immediately preceeding length) If there are multiple attribute value assertions in the RDN, the group between {2 and 2} is repeated (with different attributes). Order is not significant. Expires 11 February 1994 [Page 10] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 The encoding of a [Directory] Name for the AP-titles is the RDNs (high- order first) within 30 80 {1 - [SEQUENCE] Name -- put the RDN encodings here 00 00 }1 An Object Identifier AP-title is encoded as a primitive (see below), with the "universal" tag for an object identifier, which is 6. The integer AE-qualifer uses the universal tag for an integer, which is 2. 4. What has to be sent and received 4.1. Sequence of OSI protocol data units used OSI defines its facilities in terms of services but these are abstract constructs (they do not have to correspond to procedure calls) - the significant thing is the transmission of the resulting protocol data unit (PDU). The PDU at each layer carries (as user data) the PDU of the layer above. The different layers follow different conventions for naming the pdus. This section gives an overview of the sequence of PDUs exchanged - the details of these are given in section 6. The requirements of the application are to create a connection(strictly an association for the application-layer in OSI, but called a connection here), to send and receive data and to close the connection. The PDUs used are thus: To create connection : First create transport-level connection Initiator sends the message defined in 6.1, which is Session CONNECT carrying Presentation CONNECT request [CP] carrying ACSE A-ASSOCIATE request [AARQ] optionally carrying application data. Responder replies with the message defined in 6.2, which is Session ACCEPT carrying Presentation CONNECT response [CPA] carrying ACSE response [AARE] optionally carrying application data. - If the responder rejects the attempt, the reply will be Session REJECT. This is defined in 6.3, where the REJECT carries no user data. A received REJECT may carry Presentation, ACSE and application data, although 6.3 shows only how to reject at Session level.. To send/receive data on an connection Expires 11 February 1994 [Page 11] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 send the message defined in 6.4, which is an empty Session GIVE-TOKEN followed by Session S-DATA carrying Presentation P- DATA [TD] containing the application data (The GIVE-TOKEN is just two octets required by Session for some backwards compatibility) To close connection gracefully One side sends the message defined in 6.5, which is Session FINISH carrying P-RELEASE request carrying A-RELEASE request [RLRQ] optionally carrying application data (This side may now receive, but not send data) The other side replies with the message defined in 6.6, which is Session DISCONNECT carrying P-RELEASE response carrying A- RELEASE response [RLRE] optionally carrying application data First side disconnects transport connection on receiving the reply To close connection abruptly but also send application data Send the message defined in 6.7, which is Session ABORT carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT] carrying application data (delivery not guaranteed) On receiving Session ABORT, disconnect transport To close connection abruptly - Either sent the message defined in 6.8, which is Session ABORT carrying nothing; Or, just disconnect at transport level A group I application is assumed (by definition) not to send data on the establishment and release exchanges, a group II application will. It would be possible to use the abort-with-data facility with a group I to send a (possibly non-standardised) error message for diagnostic purposes. A special rule is used if a release collision occurs (i.e. FINISH+P- RELEASE+RLRQ received after sending the same): the side that initiated the original upper-layer connection waits and the other side replies with the DISCONNECT etc. Expires 11 February 1994 [Page 12] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 4.2. Which OSI fields are used There are a number of fields (parameters) in the pdus involved. These can be categorised by how much support must be provided by a cookbook implementation - a field may be "useful", "send-only", "fixed", "fixed with default", "internal" or "not important". Even those that are not important may be received from another implementation, but since the application has no use for them, they can be ignored. The text below describes the processing that is required for each category and which fields are in each category. "Useful" - when sending, the implementation SHOULD be able to set any (legal) value of these fields (via the upper interface from the application or via some configuration or lookup mechanism) and SHOULD pass received values for the Calling values to the application (for specific applications, these fields may be either required or unnecessary.). AARQ: Called application-process title Called application-entity qualifier Calling application-process title Calling application-entity qualifier "Send-only" - the implementation must be able to set any value of these, but can ignore any received value. Both are octet strings. Presentation selector (up to 4 octets, limited by CULR-1) Session selector (up to 16 octets, limited by base standard) "Fixed" (constant for all applications) abstract and transfer syntax identifiers for presentation context for ACSE Version numbers - 2 for session, 1 for Presentation and ACSE "Fixed with default" - the value is specific to the application. For non-ASN.1 abstract syntaxes (group I or group II only) applications, the anonymous values assigned by the OIW minimal OSI profile [CULR-3] can be used. The CULR-3 default application context can be used where a proper context name is neither available nor needed. Application context CULR-3 default is {1 0 11188 3 3} Abstract syntax identifier for application data CULR-3 anonymous name is {1 0 11188 3 1 1} Expires 11 February 1994 [Page 13] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 Transfer syntax identifier for application data CULR-3 anonymous name is {1 0 11188 3 2 1} "Internal" - an arbitrary value can be sent; a received value must be stored for use in sending. Presentation context identifiers for ACSE and the application data (always odd integers) "Not important" - any legal received value for the other fields MUST be received (i.e. the pdu is parsed successfully), but can then be ignored. There is no requirement (in this cookbook) to check the existence, value or internal format of these fields. All other fields (which includes a large number of session fields) 4.3. Encoding methods and length fields Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value structure for their encodings, but different ones. Presentation protocol and ACSE protocol use the ASN.1/BER encoding and consequently a Presentation PDU containing an ACSE PDU can be constructed or parsed as if it were a single structure. All the protocols contain pdu fields with a compound structure. If one of these is being ignored it may be necessary (for BER, not session) to determine the lengths of its components to find the length of the ignored field. Many of the lengths in the specification below will vary, dependent on the values of the fields. 4.3.1 Session items The type field of a session item is always a single octet. For session items, given a particular length, there is no flexibility: If the length is less than 255, represent as one octet If the length is greater, represent as three octets, first is 0xFF, next two are the length, high-order octet first. (Some "real" implementations are known to use the second encoding in all cases. This is wrong, but should only concern conformance testers.) Expires 11 February 1994 [Page 14] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 4.3.2 ASN.1/BER items (Presentation and ACSE) The type field for ASN.1-BER is the tag. Although it is possible for large tags (>30) to be multi-octet, there are no large tags in the protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1 if the item is constructed (i.e. the value is itself one or more ASN.1 BER items) or 0 if it is primitive. There is considerable flexibility, at senders option, in how lengths are represented in BER. There are three forms: short, long and indefinite. Short (usable only if the length is less than 127) : one octet Long (usable for *any* length) : first octet has the top bit set, the rest is a count of how many octets are holding the length value; that many subsequent octets hold the length. A long length may use more than the minimum number of octets (so 0x8400000001 is a valid representation of length 1) Indefinite (usable only for the length of a compound field) : the single octet is 0x80, then one or more items (their tag-length- values) and finally two octets of 0x00 (equivalent to tag and length of zero). To be able to interwork generally, an implementation must be able to handle any of these forms when receiving. The encodings specified in the octet sequences below use indefinite length for all constructed items. This slightly increases the number of octets sent, but means that the length of a varying field (e.g. user data, or a varying object identifier) affects only the length of the item itself, and not the enclosing lengths. It is thus possible to use the octet sequences as templates interspersed by the varying fields. 4.4. BER Encoding of values for primitive datatypes The following ASN.1 primitive datatypes are used in the thinosi stack.. Integers are encoded in twos-complement, high-order first. Unlike lengths, they must be encoded in the minimum number of octets (no leading 00 padding). Object Identifiers have a rather peculiar, but compressed encoding: Combine the first two integers of the OID into one element by multiplying the first (always 0, 1 or 2) by 40, and add the second. Each element (that one, and each subsequent integer in the OID taken on its own), is a taken as a binary number and divided into Expires 11 February 1994 [Page 15] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 7-bit "bytes". This is apportioned into bits 1-7 of the minimum number of octets. Bit 8 is one for all octets of the sequence except the last. (This means that elements of less than 127 are single octet integers.) Printable Strings - as if in ISO 646 (ASCII) OCTET STRING - just put the octets there 4.5. Unnecessary constructed encodings BER allows the sender to break some items (such as OCTET STRINGS, character strings) into several pieces (i.e. as constructed encoding) or send them as primitive. CULR-1 requires that this is only done to one level. The pieces of both OCTET STRING and character string are tagged as if they were OCTET STRING - they have the tag 04. This memo does not include any of these optional constructions, but they may be received in interworking. 5. Notation The constructs are shown in their tag - length - value form. All numbers are in hexadecimal. Comments are preceded by a '-' character. Multiple '-' mean the comment is more than just information. The tag column contains one of: single fixed octets. * in the tag field indicates one or more pdu fields (possibly constructed) that may be received but are not sent. If received they can be ignored. ! indicates the tag is defined elsewhere. . is a place holder for the column. ? preceding the tag value indicates that the field is not always present - the comment will explain. The length column contains one of explicit value Ls - a length according to session rules which depends on the total size of the value (usually constructed) La - a length according to BER rules Expires 11 February 1994 [Page 16] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 . is a placeholder yy is exactly one octet (i.e. one hex digit per y) holding part of the length The value column contains one of the hex value xxxxxx - value of varying length (sometimes constructed) {n - (n = number) the start of a constructed value n - (n=number) the end of the constructed value with the corresponding number. (The number is sometimes omitted on the innermost nest of construction) yy - as part of a value - a variable value, each y represents one hex digit ? a value, possibly constructed that may be received but is not sent. It may be ignored if received Note that all presentation lengths may be received in one of the alternative forms. All constructed lengths are shown in indefinite form. If a received length is definite, the corresponding end item (which will be shown here as 00 00 }n) will become . . }n. In the comments, the notation {n} refers to the constructed item bracketed by the {n, }n fields. 6. Octet sequences 6.1. Connection request message - CONNECT SPDU 0D Ls {1 - "SI" value for CONNECT = 13 * Ls ? - Connection Identifier 05 06 {2 - Connect/Accept Item 13 01 00 - protocol options (probably mandatory) * Ls ? 16 01 02 -- version number (bottom bit = v1, next bit =v2. -- may get offers of either or both * Ls ? . . }2 - End Connect/Accept Item 14 02 0002 - Session User Requirements (functional units) - Id (20), length (always 2), duplex fu only. -- On receipt, other bits may be set -- check that the 2 bit is set Expires 11 February 1994 [Page 17] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 * Ls ? - we do not send any Calling Session Selector ?34 Ls xxxx -- Called Session Selector (i.e. the other end's) -- up to 16 octets - you must set what the other side -- demands. - May be anything characters, binary etc. - {3} disappeared in editing C1 Ls {4 -- User Data, Identifier=193. if length is > 512, -- then identifier is 194 (hex C2) instead - CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER 31 80 {5 - [SET] --- Mode-selector (the {6} group) could possibly --- come after everything else {7} --- This will probably only be done by --- evil-minded conformance testers A0 80 {6 - Mode-selector [0] IMPLICIT SET 80 01 01 - [0] IMPLICIT INTEGER {normalmode(1)} 00 00 }6 A2 La {7 - [2] unnamed IMPLICIT SEQUENCE * La ? ?82 La xxxx - [2] Called-presentation-selector - CULR says maximum length is 4 -- must be what the other side wants A4 80 {8 - [4] Presentation-context-definition-list --- items (the outer SEQUENCEs) within the {8} list may --- be in any order. 30 80 {9 - [SEQUENCE] 02 01 01 -- Defines pcid for ACSE; received value will be -- a one or two octet odd integer 06 04 52010001 - [OID] for ACSE abstract syntax 30 80 { - [SEQUENCE] 06 02 5101 - [OID] Transfer syntax name is BER 00 00 } - end t-s list 00 00 }9 - end acse pctx defn 30 80 {10 - [SEQUENCE] 02 01 03 -- [INTEGER] Defines pcid for application data; -- received value will be a one or two octet odd -- integer 06 La xxxxxx - [OID] object identifier name of application abstract - syntax (if CULR-3 default is used, this line is - 06 06 28CC64030101) 30 80 {11 06 La xxxxxx - [OID] t-s name for application data - (if CULR-3 default is used, this line is - 06 06 28CC64030201) -- will be several of these if multiple t-s offered -- (application is Group III) -- all will have the same tag 06 00 00 }11 - end transfer syntax list for application p-ctx 00 00 }10 - end application pctx definition -- if multiple presentation contexts are offered, (Group -- IV), the {10} SEQUENCE will repeat appropriately Expires 11 February 1994 [Page 18] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 -- if multiple contexts are to be accepted, all the pcid's -- must be remembered 00 00 }8 - end of p-ctx-def-list * La ? 61 80 {12 - [APPLICATION 1] User-data - Fully-encoded 30 80 {13 - [SEQUENCE] PDV-list 02 01 01 -- [INTEGER], value is acse pcid A0 80 {14 - [0] Single-ASN1 - ACSE A-ASSOCIATE request APDU - AARQ 60 80 {15 - [APPLICATION 0] - AARQ * La ? - protocol version defaults to 1 (only one defined) A1 80 { - [1] Application-context 06 La xxxxxx -- object identifier name of application context - (if CULR-3 default is used, this line is - 06 05 28CC640303) 00 00 } -- Called application process title {16} and application -- entity qualifier may or may not be needed (see 3.4) ?A2 80 {16 - [2] Called Application-Process title ?! La xxxxxx -- see 3.5 - either a Directory Name or an oid ?00 00 }16 - end Called APtitle ?A3 80 {17 - [3] Called Application-Entity Qualifier ?! La xxxxxx -- see 3.5 ?00 00 }17 * La ? Calling AP-title and AE-qualifier may or may not be needed. ?A6 80 {18 - [6] Calling Application-Process title ?! La xxxxxx -- see 3.5 ?00 00 }18 ?A7 80 {19 - [7] Calling Application-Entity Qualifier ?! La xxxxxx -- see 3.5 ?00 00 }19 * La ? -- the user information field may or may not be required -- (not required for Group I) ?BE 80 {20 - [30] IMPLICIT SEQUENCE ?08 80 {21 - [EXTERNAL] ??06 La xxxxxx -- [OID] This is the oid identifying the transfer -- syntax used for the user data. -- It is (almost certainly) required even if only -- one transfer syntax was proposed. ?02 01 03 - [INTEGER] this is the pcid for the application data ?A0 La xxxxxx -- [0] single-ASN.1-type - the application data -- (see paragraph at end of this section below} ?00 00 }21 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }20 - end of user information field 00 00 }15 - end of AARQ 00 00 }14 - end of single-ASN-type Expires 11 February 1994 [Page 19] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 00 00 }13 - end of PDV-list 00 00 }12 - end of Presentation User-data 00 00 }7 - end of third element of CP-type SET 00 00 }5 - end of CP-type . . }4 - end of session user data . . }1 - end of CONNECT SPDU The application data carried in the EXTERNAL is shown (as A0 La xxxx) assuming it is a single-ASN.1 type, which it often will be for group II (since these tend to be OSI applications). The xxxx will be the BER encoding of the application pdu (probably something like Z-BIND or Y- INITIALIZE). The length may be indefinite. If the application data is not a single ASN.1 type, but is an octet- aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx is the value. In this case the length must be definite (unless an "unecessary" constructed encoding is used.) Identical considerations apply to the other EXTERNALs carried in the ACSE pdus. 6.2. Successful reply to connection setup If the connection attempt is succesful, the following is sent to the initiator on a T-DATA. This accept contains an item {9} in the presentation-context-result-list which is the rejection of some presentation context that was offered. This is included to show such a rejection. It is NOT included if this is the reply to the connect in 6.1. 0E Ls {1 - ACCEPT SPDU * Ls ? 05 06 {2 - Connect/Accept Item 13 01 01 - Protocol Options * Ls ? 16 01 02 - version number (this shows version 2 only) -- if version 2 was not offered, omit all of {2} * Ls ? . . }2 - End Connect/Accept Item 14 02 0002 - Session User Requirements (functional units) - duplex fu only (kernel is automatic) * Ls ? C1 Ls {3 -- User Data.( tag is C2 if length > 512 ) - CPA - P-CONNECT response 31 80 {4 - [SET] -- again, Mode-selector could come at the end A0 80 { - Mode-selector [0], length=3 80 01 01 - normal mode - [0], length=1, value=1 Expires 11 February 1994 [Page 20] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 A2 80 {5 - [2] SEQUENCE (unnamed) * La ? A5 80 {6 - [5] P-context-definition-result-list -- following result items are in the order corresponding -- to the pctx-definition-list in the connect -- this example assumes that was ACSE, user, rubbish -- with rubbish rejected 30 80 {7 - [SEQUENCE] result item for acse 80 01 00 -- [0] result, value 0 is acceptance 81 02 5101 - [1] accepted transfer syntax name = BER - note that this has an implicit tag, not 06 00 00 }7 - end result item for acse p-ctx 30 80 {8 - [SEQUENCE] result item for application-data pctx 80 01 00 - [0] value 0 is acceptance 81 La xxxxxx - [1] oid for transfer syntax, as on defintion list -- if there were several (groupIII) , the one you -- liked most 00 00 }8 - end result item for app-data p-ctx -- next SEQUENCE is a rejection of a third pctx 30 80 {9 - [SEQUENCE] result item for a rejected pctx 80 01 02 -- [0] result, value 2 is provider rejection 82 01 00 - [2] reason, value 0 is reason-not-specified -- there are other reasons, but let's keep it simple 00 00 }9 - end result item for rejected pctx 00 00 }6 - end p-ctx-def-result-list * La ? 61 80 {10 - [APPLICATION 1] User-data, Fully-encoded 30 80 {11 - [SEQUENCE] PDV-list 02 01 01 -- [INTEGER] value is pcid for ACSE, as stored from -- the pctx-definition-list on the P-CONNECT request A0 80 {12 - [0] single-ASN1-type - A-ASSOCIATE response APDU - AARE 61 80 {13 - [APPLICATION 1] identifies AARE * La ? A1 80 {14 - [1] Application-context 06 La xxxxxx - [OID] name of application context - usually the same as on AARQ, can differ 00 00 }14 A2 03 {15 - [2] result 02 01 00 - [INTEGER] value 0 means accepted 00 00 }15 A3 80 {16 - [3] result-source-diagnostic - (curiously, a non-optional field) A1 80 {17 - [1] acse-service-user 02 01 00 - [INTEGER] value 0 = null ! (why no implicit tag) 00 00 }17 - end acse-service-user 00 00 }16 - end result source diagnostic * La ? Expires 11 February 1994 [Page 21] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 -- the user information field may or may not be required - (not used for Group I) ?BE 80 {20 - [30] IMPLICIT SEQUENCE ?08 80 {21 - [EXTERNAL] -- the transfer-syntax oid is not present this time ?02 01 03 - [INTEGER] this is the pcid for the application data ?A0 La xxxx -- [0] single-ASN1-type (see note at end of 6.1) ?00 00 }21 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }20 - end of user information field 00 00 }13 - end AARE 00 00 }12 - end single-asn1-type 00 00 }11 - end PDV-list 00 00 }10 - end Presn user-data 00 00 }5 - end [2] implicit sequence in cpa 00 00 }4 - end CPA-type set . . }3 - end session userdata . . }1 - end ACCEPT SPDU 6.3. Connection rejection Refusal is at session-level, but by session user, with no reason given. This is a compromise avoiding making unfounded accusations of (session) protocol misbehaviour. If the implementation finds it does not like the received message, it is not essential to attempt to communicate with the partner why, though this may be helpful if the reason is correctly identified. (In most cases, a wise implementor will make sure an error message goes somewhere or other). 0C 03 {1 - REFUSE SPDU * Ls ? 32 01 00 - rejected by SS-user, no reason . . }1 The far-end may send interesting things explaining why you are not getting interworking. If this is a session reason, the reason code will one octet between 81 and 86. If the rejection is higher than session, this will be carried on S-REFUSE (so first octet is still 0C) and the higher pdu will appear as part of the reason code, which will start with 02. (The only remaining code is 01 = user congestion). 6.4. Data-phase TSDU This is the core of the skinny stack. The lengths shown use a particular set of choices for indefinite and definite lengths that means that the application data length only affects one field. Making the two earlier Expires 11 February 1994 [Page 22] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 indefinite lengths definite would require more calculation - adding 4 octets after the application data is assumed to be quicker. This header is also designed to be 20 octets long, thus maintaining 4-byte alignment between transport and application buffers. Implementations are recommended to use this encoding. It is possible to rapidly match incoming data against it - if there is no mismatch until the length field, the location of the beginning of the data can be determined without further analysis. SPDUs 01 00 . - S-GIVE-TOKEN - required by basic concatenation - but no parameters 01 00 . - S-DATA - no parameters - what follows is User - Information, not User Data, so is not included in the - SPDU length fields - P-DATA PPDU - TD (why TD ? Typed-data id TTD !) 61 80 {1 - User-data [APPLICATION 1] 30 80 {2 - [SEQUENCE] PDV-list 02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU - remembered by both sides 81 83yyyyyy xxxxxx -- [1] octet-aligned presentation data value(s) -- length of length (3 octets) then three octets yyyyyy -- for the length of the user data xxxxxx 00 00 }2 - End-of-contents for end of PDV-list 00 00 }1 - End-of-contents for end of Presentation User-data If the application data is in ASN.1, and a single ASN.1 value is being sent on the TSDU, the same header can be used except for the tag on the presentation data values, which becomes A0 (= [0], constructed). If there are multiple data values to be sent, this header can be expanded in several ways: a) if there are several ASN.1 values from the same presentation context, they can be concatenated and treated as an octet-aligned value (using the header as shown above, with tag 81 (or A1 - I think its primitive) or each ASN.1 value can be an item (tagged A0), one after the other b) if the data values are from different presentation contexts (group IV), each is in its own {2} group within the {1}. On receipt, for the simple octet-aligned case, the data value may itself have a constructed encoding - this will make the tag A1, and it will contain elements each tagged 04 (OCTET STRING). According to CULR-1, these elements are primitive (otherwise they would be 24 of course). Expires 11 February 1994 [Page 23] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 6.5. Closedown - release request When all is done, and you want to close down gracefully, send this on T- DATA. - FINISH SPDU 09 10 {1 - 9 identifies FINISH * Ls ? - No Transport Disconnect item - default is release Transport-connection C1 0E {2 - User data (code 193) - P-RELEASE req/ind PPDU (has no name) 61 80 {3 - [APPLICATION 1], user data, fully-encoded 30 80 {4 - [SEQUENCE] PDV-list 02 01 01 -- pcid for ACSE, remembered from setup A0 80 {5 - [0] single asn.1-type - A-RELEASE request APDU - RLRQ 62 80 {6 - [APPLICATION 2] identifies RLRQ 80 01 00 - [0] reason, value 0 means normal * La ? -- the user information field may or may not be required - ( not required for Group I) ?BE 80 {7 - [30] IMPLICIT SEQUENCE ?08 80 {8 - [EXTERNAL] -- the transfer-syntax oid is not present this time ?02 01 03 - [INTEGER] this is the pcid for the application data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }8 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }7 - end of user information field 00 00 }6 - end of RLRQ 00 00 }5 - end of single asn.1-type 00 00 }4 - end of PDV-list 00 00 }3 - end of Presentation User-data . . }2 - end of session user data . . }1 - end of FINISH SPDU 6.6. Closedown - release response On receiving a FINISH, you send this to tell the other end it is all over - Session DISCONNECT SPDU 0A 10 {1 - SI=10, DISCONNECT C1 0E {2 - User data (tag = C2 if length >512) - P-RELEASE rsp PPDU 61 80 {3 - [APPLICATION 1], user data, fully-encoded Expires 11 February 1994 [Page 24] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 30 80 {4 - [SEQUENCE] PDV-list 02 01 01 -- [INTEGER] pcid for ACSE, remembered from setup A0 80 {5 - [0] single asn.1-type - A-RELEASE response APDU - RLRE 63 80 {6 - [APPLICATION 3] identifies RLRE 80 01 00 - [0] reason, value 0 means normal * La ? -- the user information field may or may not be required - (not required for Group I) ?BE 80 {7 - [30] IMPLICIT SEQUENCE ?08 80 {8 - [EXTERNAL] -- the transfer-syntax oid is not present this time ?02 01 03 - [INTEGER] this is the pcid for the application data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }8 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }7 - end of user information field 00 00 }6 - end of RLRE 00 00 }5 - end of single asn.1-type 00 00 }4 - end of PDV-list 00 00 }3 - end of Presentation userdata . . }2 - end of session userdata . . }1 - end of DISCONNECT SPDU 6.7. Deliberate abort It is not clear whether this is any use - just clearing the Transport connection will be more effective. It goes on T-DATA, but asks for the far-side to close the T-connection. - Session ABORT SPDU 19 15 {1 - SI of 25 is ABORT 11 01 03 - Transport Disconnect PV, code 17 -- value = '...00011'b means please -- release T-conn, user abort * Ls ? C1 11 {2 - Session User Data - P-U-ABORT PPDU - ARU A0 80 {3 - [0] implicit sequence for normal mode A0 80 {4 - [0] presentation-context-identifier-list 30 80 {5 - [SEQUENCE] 02 01 01 - [INTEGER]pcid for ACSE 06 02 5101 - [OID] for acse transfer syntax = BER 00 00 }5 -- there will be one {6} group for each application -- presentation context that is used in this message -- if there is no user data, the {6} group can be -- omitted Expires 11 February 1994 [Page 25] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 30 80 {6 02 01 03 - [INTEGER] pcid for application data 06 La xxxxxx - [OID] transfer syntax for application data 00 00 }6 00 00 }4 - end of presentation-context-identifier-list 61 80 {7 - [APPLICATION 1], user data, fully-encoded 30 80 {8 - [SEQUENCE] PDV-list 02 01 01 - [INTEGER] pcid for ACSE as on CP PPDU A0 05 {9 - [0] single asn.1-type - A-ABORT APDU - ABRT 64 80 {10 - [APPLICATION 4] identifies ABRT 80 01 01 - [0] value 1 is acse-service-provider -- the user information field may or may not be required ?BE 80 {11 - [30] IMPLICIT SEQUENCE ?08 80 {12 - [EXTERNAL] -- the transfer-syntax oid is not present this time -- (according to CULR-1) ?02 01 03 - [INTEGER] this is the pcid for the application data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }12 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }11 - end of user information field 00 00 }10 - end of ABRT 00 00 }9 - end of single asn.1-type 00 00 }8 - end of PDV-list 00 00 }7 - end of Presentation user-data 00 00 }3 - end of ARU-PPDU . . }2 - end of session user-data . . }1 - end of ABORT SPDU 6.8. Provider abort Generated when an internal error occurs (i.e. something has gone mildly (?) wrong in the cookbook implementation). Rather than accuse anyone of protocol errors, we just abort at session. ABORT SPDU 19 03 {1 - SI=25 = ABORT SPDU 11 01 09 - Transport Disconnect PV, code 17 -- value = '...01001'b release T-conn -- no reason * Ls ? . . }1 Expires 11 February 1994 [Page 26] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 6.9. Abort accept If a Session abort (of any kind) is sent, it is possible that the far- end will send back an abort accept. If this happens, disconnect the transport. (The abort messages above do not propose that the transport connection be reused, and in this case, an abort accept is just the far- end passing the transport-disconnect initiative back.) This session message need never be sent - just disconnect transport on receiving an abort. ABORT ACCEPT SPDU 1A 00 . - SI=26 = ABORT ACCEPT SPDU, no parameters 7. References [CULR-1] Working draft 13 of Common upper layer requirements - Part 1 : basic connection-oriented requirements; EWOS. (A later draft will be proposed as ISP 11188/1) [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal OSI upper layers facilities (A later draft will be proposed as ISP 11188/3) [ISO8072] Information processing systems - Open Systems Interconnection - Transport service definition; ISO, 1986. [ISO8073] Information processing systems - Open Systems Interconnection - Transport protocol specification; ISO, 1986. [ISO8326] Information processing systems - Open Systems Interconnection - Basic connection oriented session service definition; ISO, 1987. (or review copy of revised text = ISO/IEC JTC1/SC21 N4657, April 1990) [ISO8327] Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification; ISO, 1987. (or review copy of revised text = ISO/IEC JTC1/SC21 N4656, April 1990) [ISO8649] Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element; ISO, 1989 [ISO8650] Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element; ISO, 1989 [ISO8822] Information processing systems - Open Systems Interconnection - Connection-oriented presentation service definition; ISO, 1989 [ISO8823] Information processing systems - Open Systems Interconnection - Connection-oriented presentation protocol specification; ISO, 1989 Expires 11 February 1994 [Page 27] INTERNET DRAFT ThinOSI upper-layers cookbook August, 1993 [ISO8824] Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990 [ISO8825] Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One, ISO/IEC 1990 [RFC1006] ISO transport services on top of the TCP; Rose M.T, Cass D.E, 1987 [ISO9594] Information technology - Open Systems Interconnection - The Directory; ISO/IEC, 1990 [RFC 1274] The Internet and Cosine Schema; Kille, S.H., 1992 8. Other notes The Session, Presentation and ACSE standards have been the subject of considerable amendment since their first publication. The only one that is significant to this cookbook is Session addendum 2, which specifies session version 2 and unlimited user data. There are plans to produce new editions of these standards, incorporating all the amendments, published in early 1994. The coding choices made in the cookbook are (nearly) those made by the "Canonical Encoding Rules", which are a form of Basic Encoding Rules with no optionality, specified in an amendment to ISO/IEC 8825 (currently a new part of 8825 at Draft International Standard status, but likely to be folded into a new edition of 8825). A defect report has been proposed against Presentation and ACSE, suggesting that a note to the protocol specifications recommend use of the canonical encoding options when sending, and then optimising for this on receipt. 9. Author's Address Peter Furniss Peter Furniss Consultants 58 Alexandra Crescent Bromley, Kent BR1 4EX UK Phone & fax +44 81 313 1833 Email: P.Furniss@ulcc.ac.uk Expires 11 February 1994 [Page 28]